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/J The present invention relates to a computer method and system for placing 

an order and, more particularly, to a method and system for ordering items over the 
rlo Intemet. 

BACKGROUND 

£3 The Litemet comprises a vast number of computers and computer networks 

that are interconnected through communication links. The interconnected computers 
exchange information using various services, such as electronic mail, Gopher, and the 

15 World Wide Web ("WWW"). The WWW service allows a server computer system (/.e., 
Web server or Web site) to send graphical Web pages of information to a remote client 
computer system. The remote client computer system can then display the Web pages. 
Each resource (e.g., computer or Web page) of the WWW is uniquely identifiable by a 
Uniform Resource Locator ("URL"). To view a specific Web page, a client computer 

20 system specifies the URL for that Web page in a request {e.g., a HyperText Transfer 
Protocol ("HTTP") request). The request is forwarded to the Web server that supports 
that Web page. When that Web server receives the request, it sends that Web page to the 
client computer system. When the client computer system receives that Web page, it 
typically displays the Web page using a browser. A browser is a special-purpose 

25 application program that effects the requesting of Web pages and the displaying of Web 
pages. 



[24976-80 19/801 9-app.doc] 




Currently, Web pages are typically defined using HyperText Markup 
Language ("HTML"). HTML provides a standard set of tags that define how a Web page 
is to be displayed. When a user indicates to the browser to display a Web page, the 
browser sends a request to the server computer system to transfer to the client computer 
5 system an HTML document that defmes the Web page. When the requested HTML 
document is received by the client computer system, the browser displays the Web page 
as defmed by the HTML document. The HTML document contains various tags that 
control the displaying of text, graphics, controls, and other features. The HTML 
docimient may contain URLs of other Web pages available on that server computer 

I ft) system or other server computer systems. 

- J The World Wide Web is especially conducive to conducting electronic 

commerce. Many Web servers have been developed through which vendors can advertise 
and sell product. The products can include items (e.g., music) that are delivered 

I I electronically to the purchaser over the Intemet and items (e.g., books) that are delivered 
lis through conventional distribution channels {e,g., a common carrier). A server computer 
II system may provide an electronic version of a catalog that lists the items that are 
U available. A user, who is a potential purchaser, may browse through the catalog using a 

browser and select various items that are to be purchased. When the user has completed 
selecting the items to be purchased, the server computer system then prompts the user for 
20 information to complete the ordering of the items. This purchaser-specific order 
information may include the purchaser's name, the purchaser's credit card number, and a 
shipping address for the order. The server computer system then typically confmns the 
order by sending a confirming Web page to the client computer system and schedules 
shipment of the items. 

25 Since the purchaser-specific order information contains sensitive 

information (e.g., a credit card number), both vendors and purchasers want to ensure the 
security of such information. Security is a concem because information transmitted over 
the Intemet may pass through various intermediate computer systems on its way to its 
final destination. The information could be intercepted by an unscrupulous person at an 

30 intermediate system. To help ensure the seciuity of the sensitive information, various 
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encryption techniques are used when transmitting such information between a chent 
computer system and a server computer system. Even though such encrypted information 
can be intercepted, because the information is encrypted, it is generally useless to the 
interceptor. Nevertheless, there is always a possibility that such sensitive information 
5 may be successfully decrypted by the interceptor. Therefore, it would be desirable to 
minimize the sensitive information transmitted when placing an order. 

The selection of the various items from the electronic catalogs is generally 
based on tiie "shopping cart" model. When the purchaser selects an item from the 

3 ^ 

electronic catalog, the server computer system metaphorically adds that item to a 
]p shopping cart. When the purchaser is done selecting items, then all the items in the 

shopping cart are "checked out" (/' ordered) when the purchaser provides billing and 
4^ shipment information. In some models, when a purchaser selects any one item, then that 

item is "checked out" by automatically prompting the user for the billing and shipment 
)z information. Although the shopping cart model is very flexible and intuitive, it has a 

Hi 5 downside in that it requires many interactions by the purchaser. For example, the 

f j 

n purchaser selects the various items from the electronic catalog, and then indicates that the 
selection is complete. The purchaser is then presented with an order Web page that 
prompts the purchaser for the purchaser-specific order information to complete the order. 
That Web page may be prefiUed with information that was provided by the purchaser 

20 when placing another order. The information is then validated by the server computer 
system, and the order is completed. Such an ordering model can be problematic for a 
couple of reasons. If a purchaser is ordering only one item, then the overhead of 
confirming the various steps of the ordering process and waiting for, viewing, and 
updating the purchaser-specific order information can be much more than the overhead of 

25 selecting the item itself This overhead makes the purchase of a single item cumbersome. 
Also, with such an ordering model, each time an order is placed sensitive information is 
transmitted over the Intemet. Each time the sensitive information is transmitted over the 
Intemet, it is susceptible to being intercepted and decrypted. 
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BRIEF DESCRIPTION OF THE DRAWINGS 



Figures lA-lC illustrate an embodiment of single-action ordering. 

Figure 2 is a block diagram illustrating an embodiment of a system that 
supports single-action ordering. 

Figure 3 is a flow diagram of an embodiment of a routine that enables 
single-action ordering for a customer. 

Figure 4 is a flow diagram of an embodiment of a routine to generate a Web 
page in which single-action ordering is enabled. 

Figure 5 is a flow diagram of an embodiment of a routine which processes a 
single-action order. 

Figure 6 is a flow diagram of an embodiment of a routine for generating a 
single-action order summary Web page. 

Figure 7 is a flow diagram of an embodiment of a routine that implements 
an expedited order selection algorithm. 

Figures 8A-8C illustrate a hierarchical data entry mechanism in one 

embodiment. 

Figures 9A-9B illustrate one embodiment of the use of a single-action to 
give an item as a gift to one or more recipients. 

Figure 10 illustrates an embodiment of a grid for creation of a group and the 
entry of identifying information for recipients associated with the group (i.e., members). 

Figure 1 1 is a flow diagram of an embodiment of the overall flow of the gift 
delivery system. 

Figure 12 is a block diagram illustrating the components of an embodiment 
of the gift delivery system. 

Figure 13 is a state diagram illustrating the various states of a gift order in 
one embodiment. 

Figure 14 is a flow diagram of an embodiment of a routine that controls the 
receiving of gift orders. 
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Figure 15 is a flow diagram of an embodiment of a routine that controls the 
attempt at first contact of the recipient. 

Figure 16 is a flow diagram of an embodiment of a routine that controls the 
processing of the initial voice telephone contact. 
5 Figure 17 is a flow diagram of an embodiment of a routine that controls the 

processing of the initial response. 

Figure 18 is a flow diagram of an embodiment of a routine that controls the 
collecting of additional contact information. 

at 

~i Figure 19 is a flow diagram of an embodiment of a routine that controls the 

^o verifying of the delivery information. 

'^J Figures 20A-20D illustrate an embodiment of multi-procurement option 

ordering. 

Figures 21A-21C illustrate an embodiment of adding an additional customer 
O procurement option. 

id5 Figure 22 illustrates an embodiment of adding an additional recipient 

1 1 procurement option. 

C2 Figure 23 illustrates an embodiment of multi-procurement option ordering 

after an additional customer procurement option has been added. 

Figure 24 is a block diagram illustrating an embodiment of a system for 
20 multi-procurement option ordering. 

Figure 25 is a flow diagram of an embodiment of the Generate Item Web 

Page routine. 

Figure 26 is a flow diagram of an embodiment of the Process Selection Of 
Procurement Option routine. 
25 Figure 27 is a flow diagram of an embodiment of the Create New Customer 

Procurement Option subroutine. 

Figure 28 is a flow diagram of an embodiment of the Create New Recipient 
Procurement Option subroutine. 

Figures 29A-29B illustrate example results of multi-procurement option 
30 ordering in one embodiment. 
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Figure 30 is a flow diagram of an embodiment of the Generate Order Web 
Page Summary routine. 

Figures 31A-31G illustrate an embodiment of multi-procurement option 

ordering. 

5 Figures 32A-32B illustrate an embodiment of a user's address book from 

which procurement options can be determined. 

Figure 33 illustrates an embodiment of multi-procurement option ordering 
used with items in a user's shopping cart. 
'l^l Figure 34 illustrates an embodiment of single-action ordering from a user's 

MO wish list. 

Figure 35 illustrates an embodiment of a post-order summary page from 
%• which order options can be modified. 

L DETAILED DESCRIPTION 

L i 

1.^ A method and system for ordering of items in a client/server environment is 

J: ^15 described. In some embodiments, a single-action ordering system is used to reduce the 
number of purchaser interactions needed to place an order and to reduce the amount of 
sensitive information that is transmitted between a client system and a server system. 

In one embodiment, the server system assigns a unique client identifier to 
each client system. The server system also stores purchaser-specific order information 
20 for various potential purchasers. The purchaser-specific order information may have 
been collected from a previous order placed by the purchaser. The server system maps 
each client identifier to a purchaser that may use that client system to place an order. The 
server system may map the client identifiers to the purchaser who last placed an order 
using that client system. When a purchaser wants to place an order, the purchaser uses a 
25 client system to send the request for information describing the item to be ordered along 
with its client identifier. The server system determines whether the client identifier for 
that client system is mapped to a purchaser. If so mapped, the server system determines 
whether single-action ordering is enabled for that purchaser at that client system. If 
enabled, the server system sends the requested information (e.g., via a Web page) to the 
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client computer system along with an indication of the single action to perfomi to place 
the order for the item. When single-action ordering is enabled, the purchaser need only 
perform a single action (e.g., click a mouse button) to order the item. When the 
purchaser performs that single action, the client system notifies the server system. The 
5 server system then completes the order by adding the purchaser-specific order 
information for the purchaser that is mapped to that client identifier to the item order 
information (e.g., product identifier and quantity). Thus, once the description of an item 
is displayed, the purchaser need only take a single action to place the order to purchase 
J;? that item. Also, since the chent identifier identifies purchaser-specific order information 
already stored at the server system, there is no need for such sensitive information to be 

= s 
I 

J transmitted via the hitemet or other communications medium, 
jf Figures lA-lC illustrate one embodiment of single-action ordering. Figure 

lA illustrates the display of a Web page describing an item that may be ordered. This 
ti example Web page was sent from the server system to the client system when the 
f=a5 purchaser requested to review detailed information about the item. This example Web 
page contains a summary description section 101, a shopping cart section 102, a single- 
s' action ordering section 103, and a detailed description section 104. One skilled in the art 
would appreciate that these various sections can be omitted or rearranged or adapted in 
various ways. In general, the purchaser need only be aware of the item or items to be 

20 ordered by the single action and of the single action needed to place the order. The 
summary description and the detailed description sections provide information that 
identifies and describes the item(s) that may be ordered. The shopping cart section 
provides the conventional capability to add the described item to a shopping cart. The 
server system adds the summary description, the detailed description, and the shopping 

25 cart sections to each Web page for an item that may be ordered. The server system, 
however, only adds the single-action ordering section when single-action ordering is 
enabled for that purchaser at that client system. (One skilled in the art would appreciate 
that a single Web page on the server system may contain all these sections but the single- 
action ordering section can be selectively included or excluded before sending the Web 

30 page to the client system.) This example single-action ordering section allows the 
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purchaser to specify with a single click of a mouse button to order the described item. 
Once the purchaser clicks the mouse button, the item is ordered, unless the purchaser then 
takes some action to modify the order. The single-action ordering section contains a 
single-action ordering button 103 a, purchaser identification subsection 103b, and single- 
action ordering information subsections 103 c and 103d. The purchaser information 
subsection displays enough information so that the purchaser can verify that the server 
system correctly recognizes the purchaser. To reduce the chances of sensitive 
information being intercepted, the server system sends only enough information so that 
the purchaser is confident that the server system correctly identified the purchaser but yet 
not enough information to be useful to an unscrupulous interceptor. The additional 
information subsections allow the purchaser to obtain various settings or obtain more 
information related to the single-action ordering. If the purchaser wants to verify the 
shipping address, the purchaser can select the "check shipping address" label. In 
response to this selection, the server system may require the purchaser to perform a 
"login" so that the identity of the purchaser can be verified before the shipping 
information is viewed or modified. The server system then sends a Web page to the 
client system for display and possible modification of the shipping address. In this way, 
the transmitting of the sensitive shipping address can be avoided unless requested by the 
verified purchaser. 

When the purchaser selects the single-action ordering button, the client 
system sends a message to the server system requesting that the displayed item be 
ordered. After the server system processes the message, the server system provides to the 
client system a new Web page that confirms receipt of the single-action order. Figure IB 
illustrates the display of a Web page confirming a single-action order. The confirming 
Web page contains essentially the same information as the Web page describing the item 
(/.e.. Figure lA) except that an order confirmation section 105 is displayed at the top of 
the Web page. The order confirmation section confirms that the order has been placed 
and provides an opportunity for the purchaser to review and change the single-action 
order. Alternatively, the confirming Web page can be identical to the Web page 
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describing the item (Le., Figure lA), except that the single-action ordering button is 
replaced with a message confirming the order. 

If a single-action ordering is not currently enabled for the client system but 
could be enabled, then the server system can generate a Web page like Figure lA, except 
5 that the single-action ordering button 103a is replaced by a single-action ordering enable 
button. Such a replacement button could contain text instructing the purchaser to click on 
the button to enable single-action ordering. When the purchaser clicks on that button, the 
server system would send the Web page of Figure lA to be displayed. Single-action 
ordering can be enabled whenever the server system has stored sufficient purchaser- 
)t) specific order information for that client system to complete a single-action order. If the 
^'l server system does not have sufficient information, then when the purchaser selects the 
4Z single-action ordering button, the server system can provide a Web page to collect the 
I' additional information that is needed. The server system may require the purchases to 
"login" so that the identify of the purchaser can be verified before the single-action 
Ml 5 ordering is enabled. 

f 5 To help minimize shipping costs and purchaser confusion, the server system 

may combine various single-action orders into a multiple-item order. For example, if a 
piu-chaser orders one item using the single-action ordering and five minutes later orders 
another item using the single-action ordering, then those orders may be cost effectively 

20 combined into a single order for shipping. The server system combines the single-action 
orders when their expected ship dates are similar. For example, if one item is 
immediately available and the other item will be available in one day, then the two single- 
action orders may be cost-effectively combined. However, if the other item will not be 
available for two weeks, then the two single-item orders would not be combined. Figure 

25 IC illustrates the display of a Web page representing four single-action orders that have 
been combined into two separate multiple-item orders based on the availability of the 
items. The order information 106 indicates that item 1 and item 2, which will be 
available in three or fewer days, have been combined into one order. The order 
information 107 indicates that items 3 and 4, which will not be available within one 

30 week, are combined into a separate order. In one embodiment, the server system may 
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combine single-action orders that are placed within a certain time period (e.g., 90 
minutes). Also, the server system may combine or divide orders when the orders are 
scheduled for shipment based on the then current availability of the items ordered. This 
delayed modification of the orders is referred to as "expedited order selection" and is 
5 described below in detail. 

Figure 2 is a block diagram illustrating an embodiment of a system that 
supports single-action ordering. This embodiment supports the single-action ordering 
over the Intemet using the World Wide Web. The server system 210 includes a server 
engine 211, a client identifier/customer table 212, various Web pages 213, a customer 
'^fo database 214, an order database 215, and an inventory database 216. The server engine 
"J receives HTTP requests to access Web pages identified by URLs and provides the Web 

is 5 

41 pages to the various client systems. Such an HTTP request may indicate that the 
J^ " purchaser has performed the single action to effect single-action ordering. The customer 
C;' database contains customer information for various purchasers or potential purchasers. 
Ml 5 The customer information includes purchaser-specific order information such as the name 
£1 of the customer, billing information, and shipping information. The order database 215 
contains an entry for each order that has not yet been shipped to a purchaser. The 
inventory database 216 contains a description of the various items that may be ordered. 
The client identifier/customer table 212 contains a mapping from each client identifier, 
20 which is a globally unique identifier that uniquely identifies a client system, to the 
customer last associated with that client system. The client system 220 contains a 
browser and its assigned client identifier. The client identifier is stored in a file, referred 
to as a "cookie." In one embodiment, the server system assigns and sends the client 
identifier to the client system once when the client system first interacts with the server 
25 system. From then on, the client system includes its client identifier with all messages 
sent to the server system so that the server system can identify the source of the message. 
The server and client systems interact by exchanging information via communications 
link 230, which may include transmission over the Intemet. 

One skilled in the art would appreciate that the single-action ordering 
30 techniques can be used in various environments other than the Intemet. For example, 
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single-action ordering can also be in an electronic mail environment in which an item is 
described in an electronic mail message along with an indication of the single action that 
is to be performed to effect the ordering of the item. Also, various commimication 
channels may be used such as local area network, wide area network, or point-to-point 
5 dial up connection. Also, a server system may comprise any combination of hardware or 
software that can generate orders in response to the single action being performed. A 
client system may comprise any combination of hardware or software that can interact 
with the server system. These systems may include television-based systems or various 
^ Other consumer products through which orders may be placed. 

Figure 3 is a flow diagram of an embodiment of a routine that enables 

"^J single-action ordering for a customer. To enable single-action ordering, a server system 

11 

jf needs to have information about the customer that is equivalent to the purchaser-specific 
order information. The server system can obtain this information in various ways. First, 

Ef the server system could ask the customer if they would like to have single-action ordering 

1:^5 enabled. If so, then the server system could prompt the customer using a Web page for 
the purchaser-specific order information. Second, the server system could also save the 

^3 purchaser-specific order information collected when an order is placed conventionally. 
The server system could, either automatically or with the customer's assent, enable 
single-action ordering. In step 301, the server system retrieves the client identifier that . 
20 was sent by the client system. In step 302, the server system updates the client 
identifier/customer table to indicate that the generated client identifier has been 
associated with that customer. In step 303, the server system sets a flag indicating that 
single-action ordering is enabled for that client identifier and that customer combination. 
That flag may be stored in the client identifier/customer table. In step 304, the server 
25 system supplies a confirming Web page to the client system. The next time a purchaser 
attempts to order an item, the client system will supply its client identifier to the server 
system. If single-action ordering is enabled for that purchaser, the server system will 
assume that the purchaser is the customer associated with that client identifier in the 
client identifier/customer table. Thus, a purchaser may not want to allow the server 
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system to enable single-action ordering if there is a possibility that someone else may use 
that same client system. 

Figure 4 is a flow diagram of an embodiment of a routine to generate a Web 
page in which single-action ordering is enabled. When single-action ordering is enabled, 
5 the server system generates a Web page describing an item as is conventionally done and 
then adds a single-action ordering section. In one embodiment, the server system adds 
partial purchaser-specific order information to the section. This information may include 
the customer's name, a shipping address moniker selected by the purchaser (e,g., "at 
home"), and the last five digits of a credit card number or a nickname selected by the 
Llo purchaser. Such partial information should be the minimum information sufficient to 
^ j indicate to the purchaser whether or not the server system is using the correct purchaser- 
Specific order information. In step 401, the server system generates a standard shopping 
cart-type Web page for the item. In step 402, if the single-action ordering flag has been 
Cj set for the client identifier and customer combination, then the server system continues at 
Ij5 Step 403, else the server system completes. In step 403, the server system adds the 
If single-action section to the Web page and completes. 

5 : 
— 5- 

CI Figure 5 is a flow diagram of an embodiment of a routine which processes a 

single-action order. When a purchaser performs the single action needed to place an 
order, the client system notifies the server system. The server system then combines the 

20 purchaser-specific order information for the customer associated with the client system 
with the item order information to complete the order. The single-action order may also 
be combined with other single-action orders and possibly with other conventionally 
placed orders to reduce shipping costs. In one embodiment, single-action orders can be 
combined if they are placed within a certain time period of each other (e.g., 90 minutes). 

25 This routine illustrates the combining of the single-action orders into a short-term order 
(e.g., available to be shipped in less than a week) and a long-term order (e.g., available to 
be shipped in more than a week). One skilled in the art would appreciate that the single- 
action orders can be combined in various ways based on other factors, such as size of 
shipment and intermediate-term availability. In step 501, if the item is expected to be 

30 shipped in the short term, then the server system continues at step 502, else the server 
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system continues at step 505. In step 502, if a short-term order has akeady been opened 
for the purchaser, then the server system continues at step 504, else the server system 
continues at step 503. In step 503, the server system creates a short-term order for the 
purchaser. In step 504, the server system adds the item to the short-term order and 
5 continues at step 508. In step 505, if a long-term order has already been opened for the 
purchaser, then the server system continues at step 507, else the server system continues 
at step 506. In step 506, the server system creates a long-term order for the purchaser. In 
step 507, the server system adds the item to the long-term order. In step 508, the server 
system generates and sends the confirmation and completes, 
tlo Figure 6 is a flow diagram of an embodiment of a routine for generating a 

^-j single-action order summary Web page. This Web page (e.g.. Figure IC) gives the user 
1^ the opportunity to view and modify the short-term and long-term single-action orders. In 
step 601, the server system adds the standard single-action order information to the Web 
ti page. In step 602, if a short-term order is open, then the server system adds the short- 
^ J5 term order to the Web page in step 603. In step 604, if a long-term order is open, then the 
ll server system adds the long-term order information to the Web page in step 605 and 
U completes. 

Figure 7 is a flow diagram of an embodiment of a routine that implements 
an expedited order selection algorithm. The goal of the expedited order selection 

20 algorithm is to minimize the number of orders sent to each destination so that shipping 
costs are reduced. A destination may be a specific shipping address plus a specific 
purchaser's billing details. Orders that are sent to the same destination are knovm as 
"sibling orders." The algorithm has two stages. In the first stage, the algorithm schedules 
for shipment the orders for destinations for which all the sibling orders are filled. An 

25 order is filled when all its items are currently in inventory (Le., available) and can be 
shipped. For each group of sibling orders, the algorithm combines those sibling orders 
into a single combined order so that only one order is currently scheduled for shipment to 
each destination. In the second stage, the algorithm combines and schedules groups of 
sibling orders for which some of the sibling orders are not filled or partially filled. The 

30 algorithm may split each partially filled sibling order into a filled sibling order and a 
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completely unfilled sibling order. The algorithm then combines all the filled sibling 
orders into a single combined order and schedules the combined order for shipment. If 
any group has only one sibling order and that order is partially filled, then the algorithm 
in one embodiment does not split that order to avoid making an extra shipment to that 
destination. 

During the second stage, the algorithm may select and schedule groups of 
sibling orders in a sequence that is based on the next fulfillment time for an item in the 
group. The next fiilfilhnent time for a group of sibling orders is the minimum expected 
fiilfillment time of the items in that group of sibling orders. For example, if a group of 
sibling orders has seven items that are not yet fulfilled and their expected fiilfilhnent 
times range from 3 days to 14 days, then the next fiilfilhnent time for that group is 3 days. 
The algorithm first schedules those groups of sibling orders with the largest next 
fiilfillment time. For example, if 6 groups have next fiilfilhnent times of 3, 5, 7, 10, 11, 
and 14 days, respectively, then the algorithm first selects and schedules the sibling orders 
in the group with the next fiilfillment time of 14 days, followed by the group with the 
next fiilfillment time of 1 1 days, and so on. By delaying the scheduling of groups with, 
short next fiilfillment times, the algorithm increases the chances of additional items 
becoming available (because of the shortness of the next fiilfillment time) and thus 
combined with the scheduled order. 

Steps 701-703 represent the first stage of the expedited order selection 
algorithm, and steps 704-706 represent the second stage of the expedited selection order 
algorithm. In steps 701-703, the algorithm loops selecting groups in which all sibling 
orders are filled and combining the orders. In step 701, the algorithm selects the next 
group with all sibling orders that are filled. In step 703, if all such groups have already 
been selected, then the algorithm continues with the second stage in step 704, else the 
algorithm continues at step 703. In step 703, the algorithm combines and schedules the 
orders in the selected group and loops to step 701. In step 704, the algorithm selects the 
next group of sibling orders that has the largest next fiilfilhnent time. In step 705, if all 
such groups have already been selected, then the algorithm is done, else the algorithm 
continues at step 706. In step 706, the algorithm combines and schedules the orders in 
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the selected group and loops to step 704. When the expedited order selection algorithm is 
being performed, new orders and new inventory may be received. Whenever such new 
orders and new inventory is received, then the algorithm restarts to schedule and combine 
the new orders as appropriate. 
5 Although the algorithm has been described as having two stages, it could be 

implemented in an incremental fashion where the assessment of the fu"st and second 
stages are redone after each order is scheduled. One skilled in the art would recognize 
that there are other possible combinations of these stages which still express the same 

ti 

yj essential algorithm. 

jio Figures 8A-8C illustrate a hierarchical data entry mechanism in one 

embodiment. When collecting information from a user, a Web page typically consists of 

4= a long series of data entry fields that may not all fit onto the display at the same time. 
Thus, a user needs to scroll through the Web page to enter the information. When the 
data entry fields do not fit onto the display at the same time, it is difficult for the user to 
Ml 5 get an overall understanding of the type and organization of the data to be entered. The 

r J 

f J hierarchical data entry mechanism allows a user to understand the overall organization of 
the data to be entered even though the all data entry fields would not fit onto the display 
at the same time. Figure 8A illustrates an outline format of a sample form to be filled in. 
The sample form contains various sections identified by letters A, B, C, and D. When the 

20 user selects the start button, then section A expands to include the data entry fields for the 
customer name and address. Figure SB illustrates the expansion of section A. Since only 
section A has been expanded, the user can view the data entry fields of section A and 
summary information of the other sections at the same time. The user then enters data in 
the various data entry fields that are displayed. Upon completion, the user selects either 

25 the next or previous buttons. The next button causes section A to be collapsed and 
section B to be expanded so that fmancial information may be entered. Figure 8C 
illustrates the expansion of section B. If the previous button is selected, then section A 
would collapse and be displayed as shown in Figure 8A. This collapsing and expanding 
is repeated for each section. At any time during the data entry, if an error is detected, 

30 then a Web page is generated with the error message in close proximity (e.g., on the line 
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below) to the data entry field that contains the error. This Web page is then displayed by 
the client system to inform the user of the error. In addition, each of the data "entry" 
fields may not be editable until the user clicks on the data entry field or selects an edit 
button associated with the data entry field. In this way, the user is prevented from 
5 inadvertently changing the contents of an edit field. When the user clicks on a data entry 
field, a new Web page is presented to the user that allows for the editing of the data 
associated with the field. When editing is complete, the edited data is displayed in the 
data "entry" field. Because the fields of the form are thus not directly editable, neither 
"named-submit" buttons nor Java are needed. Also, the form is more compact because 

iio the various data entry options (e.g., radio button) are displayed only on the new Web 

^ J page when the field is to be edited. 

In other embodiments, a mechanism for giving a gift to an identified 

-2 recipient(s) using a single action is provided. When information is displayed describing 

u the item, the system displays an instruction to identify the recipient(s) and then to select a 

J f 

?l\5 "give" button to effect the giving of the item to the identified recipient(s). If the user is 
^ giving the gift to only one recipient, then the user enters identifying information, such as 
Cj the email address, of the recipient. If the user is giving the gift to more than one 
recipient, the user could enter the identifying information of each recipient, or 
altematively, the user could enter a group name that is associated with the identifying 
20 information for each member (/.e., recipient) of the group. The system uses the 
identifying information to identify a deUvery address for the gift. As described in more 
detail below, the system can use various databases to locate information for an identified 
recipient. 

Figures 9A-9B illustrate one embodiment of the use of a single-action to 
25 give an item as a gift to one or more recipients. Figure 9A illustrates the giving of a gift 
to one recipient. The sections 101-104 are the same as described for Figure lA. The gift 
giving section 901 contains an instruction subsection 901a, an identifying information 
subsection 901b, and a single-action giving subsection 901c. To effect the giving of the 
item to a recipient, the user enters the email address of the recipient in the identifying 
30 information subsection 90b and then selects the single-action giving subsection 901c. 
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The system receives the email address and uses the email address to locate the delivery 
address for the recipient as described below in detail. The system bills the item to the 
user based on information stored for that user for single-action ordering and ships the 
item to the recipient at the delivery address. As described below, the system can allow 
5 many different types of identifying information to be specified by the user. 

Figure 9B illustrates the giving of a gift to multiple recipients. The gift 
giving section 902 contains an instruction subsection 902a, a group name subsection 
902b, and a single-action giving subsection 902c. To effect the giving of the item to 
multiple recipients, the user inputs a name of the group that identifies the recipients into 
^0 the group name subsection 902b and then selects the single-action giving subsection 
902c. The system uses the group name to identify a hst of recipients who are associated 

LI 

j: with the group name. Figure 10 illustrates a grid for creation of a group and the entry of 
y identifying information for recipients associated with the group (/.e., members). The user 
^2 enters the group name in group name section 1001 and then enters information relating to 
h^5 the recipients in each row of the member information section 1002. The user can enter as 
f 5 much information about each recipient associated with the group as is known by the user. 
^ ^ For example, the user may enter only the email address for some users, while entering the 
name, email address, and delivery address of other recipients. When the system is 
requested to give an item to each recipient associated with a group, the system uses the 
20 information stored for each recipient to identify additional information need to effect the 
delivery of the gift as described below. The system may also store the identified 
additional information for each recipient so that when another item is subsequently given 
to that recipient, the additional information needed to effect the delivery of the item can 
be quickly retrieved. Altematively, a single address book for a user containing the 
25 information for all possible recipients can be maintained. The user specifies a group by 
indicating some of the recipients whose addresses are in the address book. The use of 
address books facilitates, the maintaining of multiple groups that have one or more 
recipients in common. In addition, a user can at any time provide additional information 
about a recipient to facilitate the retrieval of sufficient information to effect the delivery 
30 of an item. 
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A computer-based method and system for coordinating the delivery of gifts 
by receiving gift orders, collecting additional delivery information that is not specified in 
the gift orders, and delivering gifts based on the additional delivery information is also 
provided. In one embodiment, the gift delivery system receives gift orders via Web pages 
provided on the WWW. The gift orders specify a gift that is to be delivered to a 
recipient. The recipient may be identified by information that does not include the 
delivery address of the recipient. For example, the recipient may be only identified by a 
name and contact information such as an electronic mail address or a telephone number. 
The gift delivery system attempts to contact the recipient to obtain sufficient delivery 
information. If the contact is not successful, the gift delivery system searches various 
databases of information to identify additional contact information. If sufficient delivery 
information is obtained, the gift is delivered to the recipient and the gift giver is notified 
accordingly. If, however, sufficient delivery information cannot be obtained, the gift 
giver is notified that the gift cannot be delivered. 

Figure 1 1 is a flow diagram of an embodiment of the overall flow of the gift 
delivery system. In step 1 101, the gift delivery system receives the order for a gift fi'om a 
gift giver. In one embodiment, the order is received via access through a Web page, but 
may also be received via other modes of communication, such as a voice telephone call, 
postal mail, facsimile, or electronic mail. In step 1102, the gift delivery system attempts 
to contact the recipient of the gift. The gift order may specify contact information for the 
recipient, such as an electronic mail address or a telephone number of the recipient. 
Based on the contact information provided with the gift order, an attempt via electronic 
mail or an automated voice telephone call is made to initially contact the recipient and 
gather sufficient delivery information. Altematively, a person may attempt to make a 
voice telephone contact with the recipient. In step 1103, if the initial contact is 
successful, then the system continues at step 1106, else the system continues at step 1104. 
In step 1104, the system attempts to collect additional contact information. The system 
can obtain the additional contact information through various database sources using the 
information provided with the gift order. For example, the system can use the recipient's 
name or the recipient's electronic mail address to access Internet-based database systems. 
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In step 1105, if the system obtains additional contact information from these additional 
sources, then the system loops to step 1102 to attempt to contact the recipient using the 
additional contact information, else the system continues at step 1111. In step 1106, the 
system collects delivery information from the successfiil contact. For example, if the 
successfiil contact is a phone call, the operator making the phone call preferably enters 
the delivery information. If the successfiil contact is an electronic mail exchange, the 
system preferably parses the recipient's reply message to collect the delivery information. 
In step 1 107, the system verifies that the delivery information is correct. The system may 
use various databases, which contain lists of all proper street addresses, to verify the 
address. In step 1108, if the delivery information is verified, then the system continues at 
step 1 109 to send the gift to the recipient, else the system continues at step 1111. In step 
1109, the system sends the gift to the recipient. In step 1110, the system sends an 
electronic mail to the gift giver providing notification that the gift has been sent 
successfiilly. In step 1 1 1 1, if sufficient delivery information could not be gathered or the 
delivery information could not be verified, then the system sends a message (e.g., via 
electronic mail) to the gift giver providing notification that the gift could not be delivered 
and is being placed on hold. 

In an additional embodiment (not shown), if an attempt to contact the 
recipient is unsuccessfiil in step 1103, then the system attempts to obtain additional 
delivery information for the recipient from sources other than the recipient, such as 
databases and other sources similar to those discussed below in conjunction with Figure 
8. If the system is able to obtain sufficient delivery information for the recipient in this 
manner, the system preferably sends the gift to the recipient using the obtained delivery 
information. 

Figure 12 is a block diagram illustrating the components of an embodiment 
of the gift delivery system. Computer system 1201 contains a central processing unit, 
memory, and peripheral devices, such as a disk drive and CD-ROM. The gift delivery 
system includes an order entry system 1202 and an order delivery system 1203. The 
order entry system provides a user interface for a gift giver to input a gift order. The 
order entry system in one embodiment comprises a Web page that accesses a gift 
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database 1204. The gift giver uses the Web page provided to select which gift should be 
sent to the recipient. In addition, the gift giver provides information describing the 
recipient. The order entry system then stores the order information in the order database 
1205. The gift delivery system controls the locating of additional delivery information so 
that the gift can be successftilly delivered to the recipient. The gift delivery system 
retrieves information from the order database and attempts to contact the recipient based 
on the information provided with the gift order. If the recipient cannot be contacted 
based on that information, then the gift delivery system accesses other database sources, 
such as the customer database 1206 and Internet-based databases 1208 to gather 
|0 additional contact information for the recipient. 
'4 Figure 13 is a state diagram illustrating the various states of a gift order in 

1= one embodiment. A gift order can be in one of six states: received, response pending, 
^ verifying delivery information, collecting additional contact information, on hold, and 
I scheduled for delivery. Initially, when an order is received, the system places the order in 
as the received state 1301. When the system attempts to contact the recipient using the 
i information provided by the gift giver, the gift order changes to a response pending state 
^ 1302. The response pending state indicates that the attempt to contact is in progress, but 
no response has yet been received from the recipient. If a sufficient response is received 
from the recipient in the allotted time (e.g., 24 hours), then the gift order changes to the 
20 verifying delivery information state 1303. In the verifying delivery information state, the 
system attempts to verify that the delivery information is correct. If the delivery address 
is correct, then the gift order enters the scheduled for delivery state 1304. If the initial 
response was insufficient or not received in the allotted time, then the system places the 
gift order in the collecting additional contact information state 1305. In the collecting 
25 additional contact information state, the system searches additional sources of 
information to determine additional contact information about the recipient. If additional 
contact information can be found, then the system attempts an additional contact, and 
places the gift order in the response pending state 1302. If, however, additional contact 
information cannot be found, then the system places the gift order in the on hold state 
30 1305. 
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In a further preferred embodiment, if the initial response is insufficient, 
then the system places the gift order in a collecting additional delivery information state 
(not shown). In the collecting additional delivery information state, the system searches 
additional sources of information to obtain additional delivery information for the 
recipient. If the system is able to obtain sufficient delivery information in this manner, 
then the system places the gift order in the verify delivery information state 1303. 
Otherwise, the system places the gift order in the on hold state 1306. 

Figure 14 is a flow diagram of an embodiment of a routine that controls the 
receiving of gift orders. The receive gift order routine controls the interaction with the 
gift giver to select a gift from the gift database, to receive information on the recipient, to 
receive the payment, and to store the gift order in a database. This routine processes gift 
orders received electronically. One skilled in the art would appreciate that similar 
routines could be developed to handle other forms of receiving gift orders. In step 1401, 
the routine receives a request to send a gift from a gift giver to a recipient electronically 
via a Web page. In step 1402, the routine creates a session with the gift giver. The 
session is used to track the interaction with the gift giver and the gift delivery system. In 
step 1403, the routine receives tiie gift selection information. The gift selection 
information may be selected in response to a display of available gifts from the gift 
database. In step 1404, the routine receives recipient contact information from the gift 
giver. The recipient contact information may typically include the recipient's name and 
electronic mail address. In step 1405, the routine receives payment information. The 
payment information may be in an electronic form, such as a credit card, debit card, or 
digital cash, or in a conventional form, such as check or money order. If in conventional 
form, the gift order may be placed in an additional state waiting for receipt of the 
payment. In step 1406, if the payment is approved, then the routine continues at step 
1408, else the routine notifies the gift giver that the payment has been denied. In step 
1408, the routine assigns a gift order tracking number to the gift order. The gift order 
tracking number is used by the system to identify the gift order throughout its processing. 
In step 1409, the routine stores the gift order information in the gift order database. In 
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step 1410, the routine notifies the gift giver that the gift order has been accepted. In step 
14 11, the routine ends the session with the gift giver. 

Figure 15 is a flow diagram of an embodiment of a routine that controls the 
attempt at first contact of the recipient. The fu-st contact is made with contact 
information provided by the gift giver, such as electronic mail address and telephone 
number. If sufficient information is not provided to even attempt to contact the recipient 
initially, the gift delivery system searches various databases to obtain such information 
based on the recipient's name. In step 1501a, if the recipient's electronic mail address 
has been provided in the gift order, then the routine continues at step 1501b, else the 
routine continues at step 1502a. In step 1501b, the routine sends an electronic mail to the 
electronic mail address provided. The electronic mail contains information indicating 
that a gift is to be sent to the recipient and requests delivery information for the gift. The 
electronic mail includes the tracking number assigned by the system so that when a reply 
mail is received, the gift delivery system can determined to which gift order it 
corresponds. In step 1502a, if the recipient's phone number has been provided, then the 
routine continues at 1502b, else the routine continues various other attempts to contact 
the recipient. For example, if a facsimile number was provided, a facsimile message is 
sent to the number. In step 1502b, the routine schedules an initial telephone contact with 
the recipient. The initial telephone contact could be via an automated voice telephone 
system in which a message is left with the person answering the phone or with an 
answering machine. Alternatively, a human operator may make the initial voice contact. 
After the initial contact is made, the gift order is placed in response pending state. 

Figure 16 is a flow diagram of an embodiment of a routine that controls the 
processing of the initial voice telephone contact. This routine can either display 
information for a human operator or provide information to an automated operator. In 
step 1601, if the telephone has been answered, then the routine continues at step 1602, 
else the routine leaves the gift order still scheduled for initial contact. In step 1602, if a 
message is left either with a person or a voicemail system, then the routine continues at 
step 1603, else the routine leaves the gift order still scheduled for initial contact. In step 
1603, if a sufficient response has been received, then the routine continues at step 1605, 
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else the routine continues at step 1604. In step 1604, the routine schedules the gift order 
for searching for additional contact information relating to the recipient. In step 1605, the 
routine updates the order database with the additional information about the recipient. In 
step 1606, the routine schedules the gift order to have its delivery information verified 
5 and changes its state to verifying delivery information. 

Figure 17 is a flov^ diagram of an embodiment of a routine that controls the 
processing of the initial response. The initial response can be via electronic mail, voice 
telephone, or facsimile message. In step 1701, if the tracking number is included in the 
response, then the routine continues at step 1702, else the routine continues at step 1704. 
7£0 In step 1702, the routine verifies the tracking number using the gift order database. In 

/f Step 1703, if the tracking number has been verified, then the routine continues at step 

4 1 

4= 1706, else the routine continues at step 1704. In step 1704, the routine attempts to find 
. ' the tracking number based on the irrformation provided in the response. In step 1705, if 
)i the tracking number can be found, then the routine continues at step 1706, else the 
^^15 routine continues at step 1707. In step 1706, if the response contains sufficient delivery 
f 1 information so that the gift order can be delivered, then the routine continues at step 
1708, else the routine continues at step 1707. In step 1707, the routine schedules the 
order for searching for additional delivery information. In step 1708, the routine 
schedules the order to have its delivery information verified and changes its state to verify 
20 delivery information. 

Figure 18 is a flow diagram of an embodiment of a routine that controls the 
collecting of additional contact information. This routine searches various database 
sources based on the information provided in the gift order. For example, in step 1801, 
the routine searches Intemet-based telephone and electronic mail directories, such as 
25 Switchboard, Fourll, and Accumail. In step 1802, the routine searches various 
CD-ROM databases of telephone and electronic mail information, such as SelectPhone. 
In step 1803, the routine searches the local database of customer information. The local 
database of customer information contains information of previous recipients and gift 
givers. In step 1804, the routine searches various Intemet-based search engines, such as 
30 Digital Equipment's Alta Vista or Infoseek's Ultraseek. In step 1805, the routine uses the 
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electronic mail address or telephone number to identify the geographic location of the 
recipient. In particular, the routine accesses the InterNIC Registration Services of 
Network Services for the domain name registration of the recipient's electronic mail 
address. Altematively, the routine accesses the standard table of area codes and 
telephone number prefixes to determine the geographic locale of the recipient. The gift 
delivery system can use each of these information sources, a subset of these information 
source, or additional information source to locate the additional information. In step 
1806, the routine analyzes the retrieved information to determine the information that 
most likely corresponds to the recipients based on geographic or contextual matches. 
JU) This analysis may be done electronically or interactively with a human operator. In step 
807, the routine stores the retrieved and analyzed information and the gift order database. 
\l In step 808, the routine displays the information to a human operator and requests 
instructions on fiirther processing. The instructions can either be to place the order on 
i hold because sufficient delivery information has not been collected, send an initial 
hs contact to the recipient, or proceed with delivery of the gift. 

J Figure 19 is a flow diagram of an embodiment of a routine that controls the 

verifying of the delivery information. The gift delivery system verifies the delivery 
information to ensure that the gift is being sent to a deliverable address. In step 1901, the 
routine checks the validity of the delivery information automatically. The routine uses a 

20 database of U.S. Postal Service addresses to determine whether the delivery address is a 
valid U.S. Postal Service address. In step 1902, if the address is valid, then the routine 
continues at step 1906, else the routine continues at step 1903. In step 1903, the routine 
prompts a human operator for manual verification of the address. In step 1904, if the 
operator has manually verified the address, then the routine continues at step 1906, else 

25 the routine continues at step 1905. In step 1905, the routine notifies the gift giver that the 
order cannot be fiilfilled and places the order on hold. In step 1906, the routine schedules 
the gift for delivery and notifies the gift giver accordingly. 

Thus, an item can be ordered in a variety of ways. Ordering of items is 
discussed in U.S. Patent No. 09/151,617, filed September 11, 1998, which is hereby 

30 incorporated by reference and which is a continuation-in-part of U.S. Patent No. 
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09/046,503, filed on March 23, 1998, now abandoned, and U.S. Patent No. 08/928,951, 
filed on September 12, 1997, Patent No. 5,960,41 1. 

In some embodiments, multi-procurement option ordering of an item is 
provided in which multiple altematives for completing the ordering of the item are 
available. In particular, each user can have multiple defmed procurement options, and a 
selection or indication of one of those procurement options can be sufficient to complete 
the ordering of the item without further action by the user if that procurement option 
contains sufficient information. Altemately, a single-action ordering can be used to 
indicate the ordering of the item without further action by the user, but the information of 
a currently selected procurement option will be used to complete the ordering. Each 
procurement option can have a unique set of purchaser-specific order information (e.g., 
payment information, delivery address, delivery instructions, shipping instructions, 
wrapping instructions, etc.), can have a unique moniker (e.g., a short name such as 
"home," partial payment information, partial delivery address information, recipient 
name, etc.), and can have a variety of types of recipients (e.g., the user, an individual 
other than the user, a group of recipients, etc.) to whom an ordered item will be delivered. 
In some embodiments, each user can have one of their procurement options designated as 
their primary or default procurement option. 

In addition, in some embodiments a user can perform ordering of an item 
using a new or a partially specified procurement option. In such embodiments, the user 
can specify only a minimal amount of information needed to determine a delivery address 
(e.g., a name or other identifier for the recipient), and related information can be 
automatically retrieved (e.g., determining the dehvery address based on a specified 
recipient identifier) and/or previously specified default information for the other portions 
of the procurement option (e.g., default shipping instructions and payment information) 
can be used to complete the ordering. 

Figures 20A-20D illustrate one embodiment of multi-procurement option 
ordering. Figure 20A illustrates the display of a Web page describing an item that may be 
ordered. This example Web page was sent from a server system to a client system when 
the user requested to review detailed information about the item. The Web page contains 
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a summary description section 2001, a shopping cart section 2002, a multi-procurement 
option ordering section 2003, and a detailed description section 2004. One skilled in the 
art will appreciate that these various sections can be omitted or rearranged or adapted in 
various ways. The user need only be aware of the item or items to be ordered and of an 
action (e.g., a single action) needed to select a procurement option in order to place the 
order. The summary description and the detailed description sections provide 
information that identifies and describes the one or more items that may be ordered. The 
shopping cart section provides a conventional capability to add the described item to the 
shopping cart. The server system adds the summary description, the detailed description, 
and the shopping cart sections to each Web page for an item that may be ordered. The 
server system, however, may add the multi-procurement option ordering section only 
when multi-procurement option ordering is enabled for that user at that client system. 
One skilled in the art will appreciate that a single Web page on a server system may 
contain all these sections, and that the multi-procurement option ordering section can be 
selectively included or excluded before sending the Web page to the client system. 

When an indication of one or more of the multiple procurement options are 
displayed, the illustrated multi-procurement option ordering section allows the user to 
specify one of the procurement options, such as with a single action (e.g., a single click of 
the mouse button), to order the described item. Once the user specifies the procurement 
option, the item is ordered unless the user then takes some other action to modify the 
order. Those skilled in the art will appreciate that in other embodiments, other single 
actions by the user can cause the procurement option to be selected, including moving the 
cursor over an indication of the procurement option or circling an indication of the 
procurement option with a pointing device. In the illustrated embodiment, the multi- 
procurement option ordering section contains a multi-procurement option ordering button 
2003a and a current procurement option selection 2003b. The current procurement 
option selection subsection displays enough information so that the user can identify the 
procurement option that is currently selected, such as a moniker for that procurement 
option. To reduce the chances of system information being intercepted, the server system 
sends only enough information so that the user can uniquely identify the procurement 
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option, but not enough information to be useful to an unscrupulous interceptor or to 
another user. 

When the current procurement option selection 2003b is selected, the client 
system sends a message to the server system requesting that the displayed item be ordered 
using information for that procurement option. The current procurement option selection 
can be selected in one of a variety of v^ays, such as by clicking the mouse v^hen the 
cursor is over subsection 2003b or by selecting the multi-procurement option ordering 
button 2003a in a manner indicative of using the currently selected procurement option 
(e.g,, a left-cUck on a multi-button mouse) to complete the ordering of the item. In some 
embodiments, the initially displayed current procurement option selection is a 
procurement option that has been previously designated as a default procurement option 
for the user. 

After the server system receives a message from the client system to order 
the item using a specified procurement option, the server system retrieves information 
about the selected procurement option and uses that retrieved information to order the 
item. In some embodiments, the procurement option information is stored by the server 
system and available to the client system only when the server system provides it to the 
client system, while in other embodiments the client system stores the procurement option 
information and provides it to the server system. After the ordering of the item by the 
server system, the server system can provide to the client system a new Web page (not 
shown) that confirms receipt of the order. 

In some embodiments, the generated Web page will include the multi- 
procurement option ordering button 2003 a only if at least one of the procurement options 
for the user is currently enabled for ordering (e.g., by being explicitly designated as being 
enabled, or by containing sufficient information to allow the server system to complete 
the order). If the user has no procurement options that are currently enabled for such 
ordering, the multi-procurement option ordering button 2003 a can instead be replaced by 
a multi-procurement option ordering enable button. If the user selects the multi- 
procurement option ordering enable button, the server system can provide a Web page to 
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collect any additional information that is needed to enable one or more existing 
procurement options, or to create a new procurement option. 

Figure 20B illustrates the display of multiple procurement options 2005 for 
the current user. In the illustrated embodiment, a list of the available procurement 
5 options is displayed after the receipt of a user indication (e.g., a right-click of the mouse 
while the cursor is over the multi-procurement option ordering button 2003 a or the 
current procurement option selection 2003b). In altemate embodiments, the various 
procurement options may be added to the Web page when it is initially generated and 
HI thus displayed without user indication. In addition, available procurement options can be 

t ! . . 

jB) displayed in a manner other than a list, such as by displaying only a single entry at a time 
from a list of available entries and cycling through the entries. The procurement options 
j ? to be displayed can be determined in a variety of ways. In some embodiments, an address 
5 book of previously defmed procurement options is maintained by the server system that 
j= generates the Web page or by a third-party server. In altemate embodiments, the client 
system can provide information about potential recipients, such as by accessing an online 
Cj Rolodex database or email address book for the user. 

In the illustrated example, the current user is John Doe and the procurement 
option with the moniker "John Doe at home" is the default procurement option. The 
default procurement option can be indicated in a variety of ways, such as by being 
20 displayed as the initial current procurement option selection 2003b, by being displayed as 
the first entry 2006 in the list of available procurement options, or by being displayed in a 
manner that is distinguishable from the other procurement options (e.g., with a darkened 
border around it). 

As described above, each procurement option may have a unique set of 
25 information for completing the order of the item. Other entries in the list may thus vary 
from procurement option 2006 in a variety of ways. For example, procurement options 
2007 and 2008 each have delivery addresses at John's workplace rather than his home. 
While they have the same recipient and the same delivery address, those two procurement 
options may vary in other ways, such as by payment information (e.g., a personal credit 
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card versus a company debit account) or by shipping instructions (e.g., a common carrier 
and speed of delivery service versus electronic delivery). 

Procurement option 2009 has a recipient other than John Doe, that being 
Jolene Doe. Procurement option 2009 may be displayed for a variety of reasons, such as 
Jolene Doe being a frequent recipient of gifts from John Doe. Altemately, John and 
Jolene may share a single joint account, and thus the procurement options for the account 
may include options for both users. Yet another altemative is that the client computer 
system on which the Web page is being displayed is shared by John and Jolene, but the 
client system may supply a single unique client identifier to the server system to identify 
the current user. If so, the server system may include procurement options appropriate 
for each of the possible users associated with the client identifier if it is not possible to 
determine which user is currently using the client system. 

In some embodiments, a procurement option will be displayed only if it is 
currently enabled and thus available to complete an order for the item. In altemate 
embodiments, non-enabled procurement options are also displayed. In the illustrated 
embodiment, procurement option 2011 is a non-enabled procurement option that is 
displayed in a manner that indicates that the procurement option is not enabled (e.g., 
displayed in a dimmed manner or with an identifying mark). Procurement options can be 
non-enabled for a variety of reasons, such as due to a lack of sufficient information 
necessary to complete the ordering of the item (e.g., payment information or a delivery 
address) or based on a previous explicit user indication to non-enable that procurement 
option. In some embodiments, non-enabled procurement options can be selected and 
used to complete the ordering of the item, such as by explicitly indicating to enable the 
procurement option or by supplying additional necessary information. 

In addition to displaying a moniker to represent a procurement option, it is 
also possible to represent procurement options in other manners (e.g., when no moniker is 
defined). For example, procurement option 2012 is displayed using partial delivery 
address information in which only a portion of the numerical address is displayed. 
Altemately, portions of other procurement option information can also be displayed, such 
as payment information. 
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In some embodiments, a user can perfomi the ordering of an item by 
specifying a new procm-ement option. In the illustrated embodiment, procurement 
options 2014 and 2016 can be selected to create a new procurement option for the user or 
for a non-user recipient. After selecting one of the options, the user is prompted to 
5 supply enough information to allow the system to purchase and deliver the item. After 
supplying the information, the order will be completed in accordance with the newly 
created procurement option, as described in greater detail with respect to Figures 21A-C 
and 22. 

''ri In some embodiments, the user can select a displayed procurement option 

Mo in a maimer that does not trigger an ordering of the item, such as by right-clicking on the 
displayed procurement option. In Figure 20C, the user has selected the procurement 

L 1 

jf Option with the moniker "Jolene Doe," but has not yet selected a procurement option with 
y which to perform ordering of the item. After the procurement option with the moniker 
u "Jolene Doe" is selected, it is displayed as the current procurement option selection 
|,a5 2003b. If the user decides to complete the order using the "Jolene Doe" procurement 
:= ; option, the user can perform an order of the item using the current procurement option 
£3 selection in a variety of ways (e.g., by left-clicking on the multi-procurement option 
ordering button 2003 a or the current procurement option selection 2003b). In yet other 
embodiments, the user may select a procurement option using one display element, but 
20 perform the ordering using the selected procurement option using a separate display 
element. For example, in Figure 20D the multi-procurement option ordering button 
2003a has been replaced by a procurement option selection button 2003c and an ordering 
button 2003d. 

Those skilled in the art will appreciate that the embodiments shown in 
25 Figures 20A-20D are for illustrative purposes only, and are not intended to limit the 
scope of the invention. A user can perform a multi-procurement option ordering of one 
or more items using one of multiple available procurement options in a variety of ways. 

Figures 21A-21C illustrate an embodiment of adding an additional customer 
procurement option. The adding of an additional customer procurement option can occur 
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in a variety of ways, such as by the user explicitly entering a mode for that purpose, or by 
selection of a displayed item such as procurement option 2014 shown in Figure 20B. 

In some embodiments, it is necessary to verify the identity of a user before 
allowing the user to perform certain actions, such as adding new procurement options. 
5 User identity verification can be performed in a variety of ways. As shown in Figure 
21 A, one identity verification process involves the user supplying a user name 2101 and 
an associated password 2102. After a user's identity has been verified, some 
embodiments allow a user to specify information that can be later used in a default 
manner, such as to be included with procurement options that are added at a later time 
40 (e.g., during the same shopping trip). In the illustrated embodiment, the user can 
optionally specify credit card payment information 2103 at the time of user identity 
j; verification that will be used for new procurement options that are defined later diuing 
the shopping trip. In altemate embodiments, the payment information may be available 
u until a timer expires after a specified occurrence, such as fi-om the time the information 
La5 was originally provided, fi'om the last time the user performed an action requiring a 
\i verified user identity, or from the last time the user performed an action using a secured 
cJ connection. 

After user identity verification has been performed, or if it is not currently 
required, the user can create a new procurement option having themself as the recipient 

20 by supplying a variety of procurement option information, such as that shown in Figure 
2 IB. Since the new procurement option is for the user and the user identity is known, the 
user can be automatically selected as the current customer (and thus the name of the 
recipient is not displayed). If other types of default procurement option information had 
previously been specified, those defaults could be displayed in a manner that allows 

25 optional modification by the user, or those types of information could instead be omitted 
and the previously specified default information could be automatically used for the new 
procurement option. The procurement option information to be added includes delivery 
address information 2104, phone number contact information 2105, payment information 
2106, shipping instructions 2107, and moniker information 2108. In the illustrated 

30 embodiment, the user can also select box 2109 in order to designate that the new 
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procurement option be the default procurement option for the user. In addition, in some 
embodiments the user can specify that procurement option information that has been 
added to the new procurement option be used as default procurement option information 
for procurement options to be added in the future. In the illustrated embodiment, the user 
5 has selected box 2110 so that the specified payment information as default information 
for procurement options that are later added. Those skilled in the art will appreciate that 
other user-selectable options may be available, such as an option to treat the procurement 
option as enabled or not. Figure 21C illustrates that when the next new customer 

yj procurement option is to be added, the entry area for payment information 2106 is 

hb omitted since the previously selected default payment information will be used for this 

new procurement option. 
jz In a similar manner to that shown in Figure 2 IB, the user can create a new 

" ' procurement option having someone other than themself as the recipient by supplying a 
variety of procurement option information such as that shown in Figure 22. The user 
Ml 5 specifies the name of the recipient 2203 and, if the user has delivery address information 
f J for the recipient, a user can directly specify the address information 2204. However, 
when designating someone else as the recipient, the user may have only partial or no 
delivery address information for the recipient. In that situation, some embodiments allow 
the user to specify identifier information that can be used to identify the user, such as a 

20 phone number 2201 or an email address 2202. If the identifier information allows the 
system to contact the recipient, the system can attempt to determine the delivery address 
through such contact. Altemately, the identifier information may be sufficient to allow 
the system to automatically identify address information associated with that identifier 
(e.g., an address associated with a phone number in a White Pages directory). 

25 In the illustrated embodiment, the previously specified default payment 

information is displayed as a default selection for payment information 2206, but only 
partial information is displayed and the default information is modifiable by the user. 
Also, in addition to specifying shipping instructions information 2207 and procurement 
option moniker information 2208, the illustrated embodiment allows the user to specify 

30 gift wrapping option information 2209. Those skilled in the art will appreciate that a 
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variety of other types of information can also be specified, such as options to 
automatically add a greeting card or a message along with the item, or options to 
automatically provide confirmation to the user when the item is delivered. 

Those skilled in the art will also appreciate that multiple instances of a type 
5 of default information could be specified, such as a first set of default payment 
information for new customer procurement options and a second set of default payment 
information for new recipient procurement options, hi addition, those skilled in the art 
will appreciate that a subset of the information requested for new customer and recipient 

^ a? 

p procurement options may be sufficient for the procurement option to be used to complete 
jif) the order of an item. For example, moniker and gift wrapping instruction information 
5 1 may not be necessary to complete an item order. 

After a new procurement option has been added, that procurement option 
s may be available for the ordering of fixture items. Figure 23 illustrates that after the new 
jI customer procurement option shown on Figure 2 IB has been added, that procurement 
l}5 option is available in the list 2005 as a new procurement option 2010. In some 
CI embodiments, only customer procurement options are displayed for multi-procurement 
option ordering of an item, while in other embodiments all available procurement options 
are displayed. 

Figure 24 is a block diagram illustrating an embodiment of a system for 
20 multi-procurement option ordering. This embodiment supports multi-procurement option 
ordering over the Intemet using the World Wide Web. The server system 2410 includes a 
server engine 2411, a client identifier to customer mapping component 2412, various 
Web pages 2413, an order database 2415, an inventory database 2416, and a procurement 
information retrieval component 2418. The server system also includes a customer 
25 database 2414 which is composed of groups of customer information, such as customer 1 
information group 2440 that contains customer procurement entries 2442 and recipient 
procurement entries 2444. The other customer information groups similarly contain 
customer procurement entries and/or recipient procurement entries for those customers. 

The server system receives HTTP requests from various client systems to 
30 access Web pages that are identified by URLs, and provides the requested Web pages to 
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the requesting clients. Such HTTP requests may be in response to the user requesting a 
Web page providing information about an item that may be ordered, or instead may be in 
response to the user performing a multi-procurement option ordering of an item from 
such a Web page. 

5 When a client system requests a Web page providing information about an 

item that may be ordered, the server system attempts to add user-specific procurement 
option information to the Web page. If the identity of the user has been determined, the 
server system retrieves information from the customer database about the procurement 
entries that are stored for the customer, and provides a moniker or other set of partial 
46 procurement option information for each enabled procurement option. Such monikers 
ij allow the procurement option to be uniquely identified while protecting confidential 
3 " information. If the server system has not yet identified the identity of the user and the 
s client system supplies a client identifier that uniquely identifies that system, the server 
]l uses the client identifier to customer mapping component to identify one or more 
p 15 customers that are associated with that client system, and then provides such monikers for 
C S the procurement options stored for those customers. 

Altematively, when an HTTP request indicates in the illustrated 
embodiment that the user has performed multi-procurement option ordering of an item, 
the HTTP request includes an indication of a procurement option selected for the user 
20 (e.g., a selected moniker) that is to be used to complete the ordering of the item. When 
the server system receives such an HTTP request, the server system retrieves information 
from the procurement entry for the customer that is stored in the customer database (e.g., 
from customer procurement entries 2442 when the user is customer 1 and is ordering an 
item that is to be delivered to themself), and uses the retrieved information to complete 
25 the ordering of the item for the customer. The inventory database can be checked to 
confrnn that the ordered item is available, and the order database can be updated to 
reflect the new order. 

In some instances, an HTTP request indicates that the user has selected to 
create a new procurement option that is to be used to order the item. If so, the client and 
30 server systems attempt to collect sufficient information from the user in order to create a 
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procurement option that is enabled for ordering. When sufficient information has been 
received, the new procurement option is added to the customer information group for the 
user in the customer database, and the information for the new procurement option is 
used to complete the ordering of the item. If the client and server systems are not able to 
5 collect sufficient information to enable the new procurement option, the procurement 
information retrieval component can attempt to use the partially specified procurement 
information to automatically determine the other necessary information. For example, if 
the user has specified an identity of the recipient but has not specified a delivery address, 
y 3 the retrieval component can attempt to identify the delivery address in a variety of ways 
% as described above. Altemately, if default information has previously been specified for 
one or more types of procurement option information, the retrieval component or the 
4; server engine can use that default information if the user does not supply alternate 
y information. Even if sufficient information to complete an order cannot be currently 
)i identified, a partially specified procurement option can be created and added to the 
K 5 customer database . 

f 5 A client system such as client 2420 can communicate with the server 

system via a commuiucations mechanism 2430 in order to send HTTP requests and 
receive Web pages from the server. The client system can use a browser 2421 to send 
and receive HTTP messages and to display Web pages. As discussed above, a client 

20 system can store a unique client identifier 2422 that can be supplied to the server system. 
In addition, in some embodiments the client system can store one or more address books 
for various users that may use the client system, such as user 1 address book 2423 and 
user 2 address book 2424. If such address books exist for the current user, information in 
the address books can be used to assist in determining possible recipients for new 

25 procurement options as well as for identifying relevant procurement option information 
for new procurement options created for such recipients (e.g., delivery addresses). 

One skilled in the art will appreciate that the multi-procurement option 
ordering techniques can be used in various environments other than the Internet. For 
example, multi-procurement option ordering can also be used in an electronic mail 

30 environment in which an item is described in an electronic mail message along with an 



[24976-801 9/801 9-app.doc] 



4/1 2/00 



indication of a selection of a procurement option that is to be used to complete the 
ordering of the item. Also, various communication channels may be used, such as a local 
area network, a wide area network, or a point-to-point dial up connection. In addition, a 
server system may comprise any combination of hardware or software that can generate 
5 orders in response to selection of a procurement option. Similarly, a client system may 
comprise any combination of hardware or software that can interact with the server 
system. These systems may include television-based systems or various other consumer 
^ , products through which orders may be placed. In addition, while Web pages are often 
yl constructed using HTML, other methods can be used to create such pages, such as Java, 
ip XML, HDML, WML, CGI scripts, etc. Similarly, communication protocols other than 
. I HTTP can be used, such as WAP, TCP/IP, or FTP, as well as a variety of inter-device 
communication mechanisms, including CDPD, CDMA, GSM, PDC, PHS, TDMA, 
r FLEX, ReFLEX, iDEN, TETRA, DECT, DataTAC, Mobitex, etc. Both the client and 
J J the server system can also operate on a wide variety of operating system types (e.g., 
[55 Windows, Linux, Unix, MacOS, BEOS, PahnOS, EPOC, Windows CE, FLEXOS, OS/9, 
U JavaOS, etc), and need not share the same operating system. 

Figure 25 is a flow diagram of an embodiment of the Generate Item Web 
Page routine 2500. When multi-procurement option ordering is enabled for at least one 
procurement option for the current user, the server system generates a Web page 
20 describing an item in a conventional manner and then adds a multi-procurement option 
ordering section for that user. In one embodiment, the server system adds partial 
information for each enabled procurement option to the section (e.g., monikers for 
immediate display), while in an alternate embodiments such partial information is 
available upon request by the user. 
25 The routine begins at step 2505 where a conventional Web page describing 

the item is generated. The routine then continues to step 2510 to determine whether to 
add a shopping cart procurement section to the Web page (e.g., based on previously 
specified preferences for the user). If so, the routine continues to step 2515 to add a 
shopping cart procurement section to the Web page. After step 2515, or if it is 
30 determined in step 2510 to not add the shopping cart section, the routine continues to step 
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2520 to determine whether to add a section to the Web page that allows the user to select 
one of multiple procurement options to order the item. If so, the routine continues to step 
2525 to add such a multi-procurement option section to the Web page. After step 2525, 
or if it was instead determined in step 2520 to not add such a multi-procurement option 
5 section, the routine continues to step 2595 and ends. Those skilled in the art will 
appreciate that the information for the multi-procurement option section can be generated 
and displayed in a variety of ways. 
Q Figure 26 is a flow diagram of an embodiment of the Process Selection Of 

Procurement Option routine 2600. When the user selects a procurement option to 
complete the ordering of the item (e.g., by performance of a single action), the client 
1 1 system notifies the server system of the selected procurement option. The server system 
then retrieves the procurement option information for the selected procurement option 
I ^ and uses that information to complete the ordering of the item. The multi-procurement 
J" option order may also be combined with other multi-procurement option orders and/or 
f |15 other conventionally placed orders to reduce shipping cost. In the illustrated 
embodiment, the initially generated Web page contains a displayed element that, when 

^ ST 

selected, proceeds to display the various available procurement options. While in some 
embodiments the information for those procurement options will have previously been 
supplied to the client system, in the illustrated embodiment the client system retrieves the 
20 information to be displayed for those procurement options when the displayed element is 
selected. 

The routine begins at step 2605 where the client system receives an 
indication to display the available procurement options. The routine continues to step 
2610 to retrieve the various available defined procurement options (e.g., from the server 

25 system or from previously received information), and then continues to step 2615 to 
determine which of the retrieved options have sufficient information in order to enable 
that option for ordering. Those skilled in the art will appreciate that in alternate 
embodiments, one or more of the retrieved options may be explicitly identified as being 
enabled or not enabled, and the explicit identifications are used rather than reviewing the 

30 information stored for that procurement option. Also, those skilled in the art will 
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appreciate that in some embodiments the server system will determine which of the 
retrieved options are currently enabled and supply that information (e.g., monikers) to the 
client system (e.g., with the initial delivery of the Web page for the item), while in other 
embodiments the server system may supply some or all of the procurement option 
5 information for the various possible procurement options to the client system and the 
client system will determine which of the options are currently enabled. 

In step 2620, after the monikers for the available procurement options have 
been determined, the client system displays the monikers to the user. The routine then 
y| continues to step 2623 to display selections to the user that allow the user to create a new 
":io customer or recipient procurement option. Those skilled in the art will appreciate that in 
some embodiments one or more of these selections may not be available. The routine 

11 

J" next continues to step 2625 where the client system receives an indication from the user 
y of a selection of one of the displayed procurement options. The routine then continues to 
step 2630 to determine if the selected option is to create a new customer procurement 

S3 S 

Mi5 option. If so, the routine continues to step 2635 to execute the Create New Customer 
f J Procurement Option subroutine. After step 2635, the routine continues to step 2640 to 
" use the newly created customer procurement option information to complete the ordering 
of the item. 

It was instead determined in step 2630 that the selected option is not to 
20 create a new customer procurement option, the routine continues to step 2645 to 
determine if the selected option is to create a new recipient procurement option. If so, the 
routine continues to step 2650 to execute the Create New Recipient Procurement Option 
subroutine. The routine then continues to step 2655 to use the newly created recipient 
procurement option information to complete the ordering of the item. 
25 If it was instead determined in step 2645 that the selected option is not to 

create a new recipient procurement option, the routine continues to step 2660 to use the 
procurement option information for the selected procurement option to complete the 
ordering of the item. After steps 2640, 2655, or 2660, the routine contains to step 2695 
and ends. Those skilled in the art will appreciate that in some embodiments, some or all 
30 of steps 2635, 2640, 2650, 2655, and 2660 will be performed by the client system, while 
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in alternate embodiments those steps will be performed by the server system. Those 
skilled in the art will also appreciate that in some embodiments, the monikers for the 
available procurement options are initially displayed and thus step 2605 will not need to 
be executed. In addition, in various embodiments different groups of procurement 
options are displayed, such as only enabled procurement options, only customer 
procurement options, all procurement options for the user, all procurement options for 
one or more customers that are possible identities of the current user, etc. 

Figure 27 is a flow diagram of an embodiment of the Create New Customer 
Procurement Option subroutine 2635. The subroutine receives information to be used to 
create a new procurement option, and then adds the new procurement option to the 
customer database. In the illustrated embodiment, the user is required to specify each of 
the types of requested information, but in altemate embodiments the user will be able to 
choose not to specify requested information. 

The subroutine begins at step 2705 where it is determined if the customer 
identity has previously been verified during the shopping trip. If not, the subroutine 
continues to step 2710 to receive and confirm a customer name and password, and then 
continues to step 2715 to optionally allow the user to specify payment information to be 
used as a default for new procurement options that are added later during the shopping 
trip. 

After step 2715, or if it was instead determined in step 2705 that the 
customer identity has been verified, the subroutine continues to step 2720 to receive 
customer delivery address information. In step 2725, customer contact information (e.g., 
a phone number or email address) is received, and in step 2730 shipping information is 
received. In step 2735, the subroutine receives a display moniker for the new 
procurement option. Those skilled in the art will appreciate that in some embodiments a 
moniker for the new procurement option can be automatically generated rather than 
supphed by the user. 

The subroutine continues to step 2740 to determine if default payment 
information had already been specified (e.g., during user identity verification), and if not, 
the subroutine continues to step 2745 to receive such payment information. After step 
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2745, or if it was instead determined in step 2740 that payment infomiation has akeady 
been specified, the subroutine contains to step 2750 to add the new customer procurement 
option to the group of information in the customer database information for the user. 
Since the user has specified all of the required information, the subroutine in step 2755 
then designates the new customer procurement option as being fully specified and thus 
enabled for ordering. The subroutine continues to step 2760 to determine if the user 
desires that the new customer procurement option be the default procurement option for 
the user. If so, the subroutine continues to step 2765 to make that designation. After step 
2765, or if it was instead determined in step 2760 that the new procurement option is not 
to be the default, the subroutine continues to step 2795 and retums. 

Those skilled in the art will appreciate that in some embodiments the user 
identity will not be verified or will be verified before the ability to create a new 
procurement option is made available to the user. Those skilled in the art will also 
appreciate that there are a variety of ways of verifying user identity other than with user 
names and passwords. Also, in some embodiments, only some of the types of 
procurement option information will be solicited from the user, while in altemate 
embodiments additional types of procurement option information will be solicited. 
Similarly, in some embodiments a variety of types of default procurement option 
information may be available, while in other embodiments no such default information 
may be available. If default information is available, in some embodiments such 
information will be displayed but will be modifiable by the user, while in other 
embodiments such default information will be automatically used and the step of 
soliciting that type of information fi^om the user will not be performed. Those skilled in 
the art will also appreciate that in some embodiments the server system will request the 
various procurement option information (e.g., by sending a Web page having defined 
areas in which to add the requested information), while in altemate embodiments the 
client system will collect the procurement option information and provide the information 
to the server system. 

Figure 28 is a flow diagram of an embodiment of the Create New Recipient 
Procurement Option subroutine 2650. The subroutine receives information to be used to 
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create a new procurement option, and then adds the new procurement option to the 
customer database. In the illustrated embodiment, the user is required to specify each of 
the types of requested information, but in aUemate embodiments the user will be able to 
choose not to specify requested information. 

The subroutine begins at step 2805 where it is determined if the customer 
identity has akeady been verified during the shopping trip. If not, the subroutine 
continues to step 2810 to receive and confirm a customer name and password, and then 
continues to step 2815 to optionally allow the user to specify payment information to be 
used as a default for new procurement options that are added later during the shopping 
trip. 

After step 2815, or if it was instead determined in step 2805 that the 
customer identity has been verified, the subroutine continues to step 2820 to determine 
whether the user has available the delivery address information for the recipient. If not, 
the subroutine contains to step 2825 to receive a phone number and/or an email address 
for the recipient, and then continues to step 2830 to determine a delivery address for the 
recipient using that information. Those skilled in the art will appreciate that there are a 
variety of ways to determine a delivery address, and that there are a variety of types of 
information other than email addresses or phone numbers that can be used to determine 
such a delivery address. 

If it was instead determined in step 2820 that the user has delivery address 
information for the recipient, the subroutine contains to step 2835 to receive the recipient 
delivery address information from the user. After step 2830 or 2835, the subroutine 
contains to step 2840 to receive shipping information. The subroutine then continues to 
step 2845 to receive a display moniker for the newly created recipient procurement 
option. Those skilled in the art will appreciate that in some embodiments a moniker for 
the new procurement option can be automatically generated rather than supplied by the 
user. The subroutine next continues to step 2850 to receive information from the user 
specifying a type of gift wrapping and card to be used for items specified with this 
procurement option. 
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The subroutine next continues to step 2855 to determine if default payment 
information had aheady been specified (e.g., during user identity verification), and if not, 
the subroutine continues to step 2860 to receive such payment information. After step 
2860, or if it was instead determined in step 2855 that payment information has aheady 
been specified, the subroutine contains to step 2865 to add the new recipient procurement 
option to the customer database information for the user. After step 2865, the subroutine 
continues to step 2895 and retums. In the illustrated embodiment, the subroutine does 
not determine whether the new procurement option is fiiUy specified and thus enabled for 
ordering at the time of creation as is done for new customer procurement options (e.g., 
the determination may be dynamically made each time available procurement options for 
the user are determined, or instead this information may not be necessary because only 
customer procurement options are displayed to the user). Similarly, in the illustrated 
embodiment, recipient procurement options are not available to be default procurement 
options, and thus the user is not queried to determine whether the new procurement 
option should be the default. 

Those skilled in the art will appreciate that in some embodiments the user 
identity will not be verified or will be verified before the ability to create a new 
procurement option is made available to the user. Those skilled in the art will also 
appreciate that there are a variety of ways of verifying user identity other than with user 
names and passwords. Also, in some embodiments, only some of the types of 
procurement option information will be solicited from the user, while in alternate 
embodiments additional types of procurement option information will be solicited. 
Similarly, in some embodiments a variety of types of default procurement option 
information may be available, while in other embodiments no such default information 
may be available. If default information is available, in some embodiments such 
information will be displayed but will be modifiable by the user, while in other 
embodiments such default information will be automatically used and the step of 
soliciting that type of information from the user will not be performed. Those skilled in 
the art will also appreciate that in some embodiments the server system will request the 
various procurement option information (e.g., by sending a Web page having defined 
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areas in which to add the requested information), while in alternate embodiments the 
client system will collect the procurement option information and provide the information 
to the server system. 

Figures 29A-29B illustrate example results of multi-procurement option 
5 ordering in one embodiment. In particular, these figures illustrate the display of a Web 
page representing five items that have been ordered using different procurement options. 
Items have been aggregated based first on the procurement option used, and then based 
on the availability of the items. Thus, the order information 2910 for the customer 
procurement option with the moniker "John Doe at Home" indicates that the items 

tlio aggregated in order 2916 will be delivered in 3 days or fewer, while the item in order 

J f 
-™ ™ 

'^j 2917 will be delivered in one or more weeks. Since the two orders have different 

1 1 

1= availability times for shipping, they are not combined into one order. However, items 1 
and 2 of order 2916, which were each individually ordered using multi-procurement 
£3 option ordering, have been combined into a single order since they use the same 
II 15 procurement option and thus have the same delivery information. In one embodiment, 
J,;' the server system may combine orders that are placed within a certain time period (e.g., 
u 90 minutes). Also, the server system may combine or divide orders when the orders are 
scheduled for shipment based on the then current availability of the items ordered. Those 
skilled in the art will appreciate that in altemate embodiments, items may not be 
20 aggregated together. Altemately, in some embodiments items may be aggregated even 
when ordered using different procurement options (e.g., if the delivery address and 
shipping instructions are the same, or if the procurement options differ only by payment 
information). 

Figure 30 is a flow diagram of an embodiment of the Generate Order Web 
25 Page Summary routine 3000. The Web page produced by the routine (e.g.. Figures 29 A 
and 29B) gives the user the opportunity to view and modify short-term and long-term 
orders before the orders are processed. 

The routine begins in step 3005 where a default order summary page is 
generated. The routine then continues to step 3010 to determine if any items whose 
30 orders are not yet processed were ordered using a customer procurement option. If so. 
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the routine continues to step 3015 to select the next such customer procurement option, 
beginning with the first procurement option. The routine then continues to step 3020 to 
determine if there are any items that have been ordered using the selected procurement 
option but are not yet processed, and that are scheduled to be delivered in the short-term. 
If so, the routine continues to step 3025 to add each such item to the Web page as part of 
a single group order. After step 3025, or if it was instead determined in step 3020 that 
there are no such short-term orders, the routine continues to step 3028 to determine if 
there are any items that have been ordered using the selected procurement option but are 
not yet processed, and that are scheduled to be delivered in the long-term. If so, the 
routine continues to step 3030 to add each such item to the Web page as part of a single 
group order. After step 3030, or if it was instead determined in step 3028 that there are 
no such long-term orders, the routine continues to step 3035 to determine if there are 
other customer procurement options that have been used to order items that are not yet 
processed. If so, the routine retums to step 3015 to select the next such customer 
procurement option. Those skilled in the art will appreciate that items can be grouped in 
ways other than by short-term and long-term delivery options. 

If it was instead determined in step 3035 that there are no more such 
customer procurement options or in step 3010 that there were not any such customer 
procurement options, the routine continues to step 3040 to determine if any items whose 
orders are not yet processed were ordered using a recipient procurement option. If so, the 
routine continues to step 3045 to select the next such recipient procurement option, 
beginning with the first procurement option. The routine then continues to step 3050 to 
determine if there are any items that have been ordered using the selected procurement 
option but are not yet processed, and that are scheduled to be delivered in the short-term. 
If so, the routine continues to step 3055 to add each such item to the Web page as part of 
a single group order. After step 3055, or if it was instead determined in step 3050 that 
there are no such short-term orders, the routine continues to step 3060 to determine if 
there are any items that have been ordered using the selected procurement option but are 
not yet processed, and that are scheduled to be delivered in the long-term. If so, the 
routine continues to step 3065 to add each such item to the Web page as part of a single 
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group order. After step 3065, or if it was instead determined in step 3060 that there are 
no such long-term orders, the routine continues to step 3070 to determine if there are 
other recipient procurement options that have been used to order items that are not yet 
processed. If so, the routine retums to step 3045 to select the next such recipient 
5 procurement option. If it was instead determined in step 3070 that there are no more such 
recipient procurement options or in step 3040 that there were not any such recipient 
procurement options, the routine continues to step 3095 and ends. 

Figures 31A-31G illustrate an embodiment of multi-procurement option 

Q 

y ? ordering. Figure 3 lA illustrates the display of a Web page describing an item that may be 
*^iio ordered. This example Web page was sent from a server system to a client system when 
"J the user requested to review detailed information about the item. The Web page contains 
4; a summary description section 3101, a shopping cart section 3102, a multi-procurement 
"y option ordering section 3 103, a wish list addition section 3 104, and a detailed description 
section 3105. One skilled in the art will appreciate that these various sections can be 
M 15 omitted or rearranged or adapted in various ways. The user need only be aware of the 
item or items to be ordered and of an action (e.g., a single action) needed to select a 
procurement option and/or to place a order. The summary description and the detailed 
description sections provide information that identifies and describes the one or more 
items that may be ordered. The shopping cart section provides a conventional capability 
20 to add the described item to the shopping cart via button 3102a. Similarly, the wish list 
addition section provides the capability via button 3104a to add the described item to a 
wish Ust for the user that contains items desired by the user. After an item is added to a 
wish list and a shipping/delivery address for the user is associated with the item, others 
may typically view the list and purchase the item for the user as a gift. One skilled in the 
25 art will appreciate that a single Web page on a server system may contain all these 
sections, and that the multi-procurement option ordering section can be selectively 
included or excluded before sending the Web page to the client system. 

The illustrated multi-procurement option ordering section allows the user to 
specify one of the procurement options to be a current procurement option, such as with a 
30 single click of the mouse button over a displayed indication of a procurement option. In 
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addition, the multi-procurement option ordering section allows the user to order the 
described item, such as with a single action (e.g., a single click of the mouse button), 
using information associated with the current procurement option. Once the user 
specifies the single action to order the item, the item will be ordered unless the user then 
5 takes some other action to modify the order. 

In the illustrated embodiment, the multi-procurement option ordering 
section contains a multi-procurement option display 3103 a, which includes a current 
procurement option display 3 103b and a procurement option selection button 3 103c. The 
multi-procurement option ordering section also contains a single-action ordering button 
'^Jio 3103d and a gift indication selection option 3103e. The current procurement option 
^4 display contains enough information so that the user can identify the procurement option 
jf that is currently selected, such as a moniker for that procurement option. In the illustrated 
embodiment, when the Web page is fu-st displayed a default procurement option is 
i J selected as the current procurement option, and thus the current procurement option 
hhi5 display contains the information for the default procurement option. As is illustrated, a 
f t procurement option with the moniker "John Doe" is the default procurement option. If 
the single action ordering button is selected after the Web page is displayed (e.g., by 
clicking the mouse when the cursor is over section 3103 d), the client system sends a 
message to the server system requesting that the displayed item be ordered using the 
20 information associated with the current procurement option. 

After the server system receives a message from the client system to order 
the item using the current procurement option, the server system retrieves information 
about the procurement option and uses that retrieved information to order the item. After 
the ordering of the item by the server system, the server system can provide to the client 
25 system a new Web page (not shown) that confirms receipt of the order. 

Figure 3 IB illustrates the display of multiple procurement options available 
for the current user. In the illustrated embodiment, a dropdown list of the available 
procurement options is displayed after the receipt of a user indication (e.g., a left-click of 
the mouse while the cursor is over button 3103c). As is shown, the list includes options 
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3 103d-3 1031. In addition, as is illustrated, some of the information on the Web page may 
be obscured by the list of options, such as the wish list addition section 3104. 

The procurement options to be displayed can be determined in a variety of 
ways, including from an address book for the user of previously defmed procurement 
options maintained by the server system that generates the Web page. In addition, the 
order and format in which the procurement options are displayed can vary greatly. In the 
illustrated embodiment, the list of procurement options begins with the currently selected 
procurement option followed by two other recently selected procurement options. Since 
the default procurement option is the initial current procurement option in the illustrated 
embodiment, the first option 3103d shows the moniker for the default procurement option 
and is highlighted as the current selection. Options 3103e and 3103f follow with two 
monikers that are automatically generated (as explained in greater detail below), and the 
next option 3 103g is an option that allows the user to specify a new procurement option 
that will be added to the user's address book. Altemately, the last option in the Ust 3 1031 
allows the user to indicate a recipient to receive the item, but in the illustrated 
embodiment the recipient information will not be added to the address book. Options 
31031, 3103j, and 3103k also illustrate monikers automatically generated to be unique, 
listed in alphabetical order by the last name of the recipient specified. Option 3 103h is a 
dotted line that separates the display of the recently selected procurement options from 
the alphabetical procurement options, and in the illustrated embodiment the dotted line 
caimot be selected as a current procurement option selection. 

In the illustrated embodiment, the selection of an indication of a displayed 
procurement option causes that procurement option to become the current procurement 
option, but does not cause the item to be ordered. Thus, for example, Figure 31C 
indicates the Web page after list option 3103k (with moniker "Benjamin F- Fair") is 
selected, with the moniker for the procurement option displayed as the current 
procurement option selection 3103b. If the user decides to then complete the order by 
selecting the 3103d button, the information associated with the Benjamin F- Fair 
procurement option will be used to order the item. 
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If the user instead selects the "add new address" option 3103g, the user may 
be presented with a Web page for gathering new procurement option information such as 
is illustrated in Figure 3 ID. The procurement option information to be added can include 
a variety of types of information such as name and delivery address information 3114, 
5 phone number contact information 3115, payment information 3116, shipping 
instructions 3117, and moniker information 3118. Some of the information may also be 
optional, such as the moniker and the phone number. As indicated previously, in the 
illustrated embodiment the new information will be used to create a new entry in the 
Ji user's address book. However, in the illustrated embodiment the user can select whether 
)lo the new procurement option will be displayed as an available procurement option when a 
list of such options are next displayed, with this selection made via box 3119. In other 

1. 1 

j; embodiments additional selections may be available, such as whether to make this new 
entry the new default entry in the address book. 

If the user had selected the "send to e-mail address" option 3 1031 in Figure 
Mi5 3 IB, the user would instead be presented in the illustrated embodiment with a Web page 
fj such as is illustrated in Figure 3 IE. The information to be specified is limited here to an 
e-mail address of the recipient 3 130 and shipping instructions 3 140. In this embodiment, 
the system will attempt to determine the name and delivery address information for the 
recipient, and may use previously specified default payment information. Since a new 
20 procurement option will not be created for this recipient, moniker information is not 
needed. Those skilled in the art will appreciate that a variety of other types of 
information can also be specified. 

As previously mentioned, the illustrated item Web page also contains a gift 
indication selection option 3103e. If this gift indication is selected, as is illustrated in 
25 Figure 3 IF, then the system may perform additional processing when the single-action 
ordering button 3103d is selected. In the illustrated embodiment, the system gathers 
information relevant to a gift before an order for the item is placed. As shown in Figure 
31G, in the illustrated embodiment the user is presented with options related to how the 
item is to be supplied to the intended recipient, including whether a gift message will 
30 accompany (or precede) the item and whether the item will be gift-wrapped. Those 
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skilled in the art will appreciate that other types of information related to supplying the 
item could also be specified. In the illustrated embodiment, the user can enter a text 
message in box 3150a if they so desire, and can also select one of various types of gift 
wraps as shown in section 3160. After the user has specified any desired gift message 
5 and gift wrapping instructions, the system will proceed to place the order using that 
information in conjunction with the information from the current procurement option 
when ordering button 3 103d was selected. 

As mentioned previously, in the illustrated embodiment the address book of 

j;? the user is used to generate the list of procurement options displayed in Figure 3 IB. 
Figures 32A and 32B illustrate an example address book that would exist after the 

'^i performance of the activities described in Figures 31A-31G. In particular, the address 

^i- book includes 8 addresses 3210-3280. In addition to the addresses, the address book 
Web page includes a selectable control 3205 via which the user can enable or disable 
whether single-action ordering, including the use of the multiple available procurement 

U15 Options, is currently available for the user. The user can also add new addresses to the 

r ^ 

address book via selectable control 3207, which may cause an information collection 
^ ^ Web page to be displayed similar to that shown in Figure 3 ID. 

Each of the 8 current addresses includes a variety of delivery, payment and 
shipping information, as well as selectable controls to modify various parts of the 

20 information. Each address also includes a moniker 32X2 (e.g., 3212, 3222, . . .) and 
procurement option availability instructions 32X4. The current default procurement 
option 3210 has a default indication message 3216, and is displayed first in the address 
book in the illustrated embodiment. In the illustrated embodiment, the default entry in 
the address book will be used as the default procurement option for item-ordering Web 

25 pages generated for the user, and the entry in the address book that is the default can be 
modified from the address book, such as by selecting the control shown in message 3216. 
In alternate embodiments, each displayed entry may have a control available to make that 
entry the default entry. The rest of the entries are shown in alphabetical order. When the 
list of procurement options was displayed in Figiwe 3 IB, six existing available 

30 procurement options were displayed. They correspond to addresses 3210, 3230, 3240, 
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3250, 3260 and 3270. While address 3220 was present in the user's address box when 
the list was displayed, the procurement option availability instructions 3224 indicate that 
the address is not to be shown as an available procurement option. Address 3280 was not 
present when the list was displayed, but instead reflects the new procurement option that 
5 was created in Figure 3 ID. 

As is shown, each address has a unique moniker. Those skilled in the art 
will appreciate that moniker names can be manually specified or automatically generated 
in a variety of ways, and that in some embodiments monikers may not be required to be 
:^ unique. In the illustrated embodiment, the user is allowed to manually specify a moniker 
^10 if they wish, but is not required to do so. If a manually specified moniker is valid (e.g., 
unique, and within length and other constraints), that moniker will be displayed. 
Addresses 3210, 3220, and 3280 have manually specified monikers. In the illustrated 
y embodiment, monikers will be automatically generated based on recipient name and 
Cj delivery information if manually specified monikers are not supplied. In particular, if a 
M15 user's name (or the portion of the name that fits within the length constraints) is unique, 
then the name will be used. If multiple identical names exist but they can be 
C3 distinguished by the city name (or the part of the city name that fits within the length 
constraints), then some or all of the name followed by some or all of the city will be used. 
Similarly, if name and city are not unique, the system next checks if name and zip code 
20 are unique, and if so uses that combination. Finally, if none of the previous generation 
schemes produce a unique name, the system will append numbers to the end of the 
recipients' names. In the illustrated embodiment, potentially sensitive information such 
as a street address or phone number is not used as part of the automatic moniker 
generation scheme. 

25 As an example of the automated moniker generation scheme, addresses 

3230, 3240 and 3250 each have identical names (whether for the same person or for 
different people). Using the next check, the three addresses also have identical city 
names. Address 3250 has a unique zip code among the three addresses, however, and 
thus the moniker for address 3250 is composed of a portion of the recipient's name 

30 followed by the zip code. Since addresses 3230 and 3240 could not be differentiated 
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based on any of the tests above, they each have numbers in brackets appended after a 
portion of the recipient's name, hi a similar manner, addresses 3260 and 3270 have 
identical names but different city names, and thus the automated monikers for those 
addresses include a portion of the recipient name followed by a portion of the city name. 
5 Figure 33 illustrates an embodiment of multi-procurement option ordering 

used with items in a user's shopping cart. In particular, the illustrated shopping cart 
includes three items, those being 3310, 3320, and 3330. While items 3310 and 3320 do 
not currently have any procurement information associated with them, item 3330 is 
indicated as having been added to the shopping cart from Benjamin Franklin's Wish List. 
1 Jo Thus, this item has an associated delivery address from the wish list entry, hi addition to 

= a; 

various other quantity and price information, each item includes a gift indication selection 
4= option box 33X2. If this gift indication is selected for one or more of the items when 
y their order is completed, the system may perform additional processing as described 

previously to gather relevant information such as a gift message and gift wrapping 
Mi5 instructions. 

rj One option available to the user is to use the Proceed to Checkout button 

3307 to purchase one or more of the items. If so, the user will be prompted to specify the 
various relevant procurement information (e.g., payment information, shipping 
instructions, delivery information, etc.) for each of the items being purchased. In 

20 addition, another option available for purchasing one or more of the items is the single- 
action ordering button 3103d in conjunction with the multi-procurement option display 
3303. As described previously, the user can choose one of the available procurement 
options to be the current prociu'ement option, and then use the single-action ordering 
button to purchase the items with procurement information from that current selection. 

25 When one or more of the items in the shopping cart aheady have some 

procurement information associated with them (e.g., delivery address), this existing 
procurement information can affect the availability of the multi-procurement option 
ordering in various ways in different embodiments. In some embodiments, multi- 
procurement option and/or single-action ordering will not be available if any item has 

30 existing procurement information, or instead may not be available if there are any 
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variations in a particular type of procurement information among all of the items. In 
other embodiments, such as the illustrated embodiment, the existing procurement 
information will be merged with the procurement information from the current 
procurement option. For example, the payment information and shipping instructions for 
5 the "John Doe" procurement option will be used in purchasing each of the items, but the 
delivery address information for the procurement option will be used only with items 
3310 and 3320 (since item 3330 already has delivery address information). Those skilled 
in the art will appreciate that such use of procurement option information can be altered 
^ ^' in a variety of ways. 

Uo Figure 34 illustrates an embodiment of single-action ordering from a user's 

wish list. In particular, Benjamin Franklin's wish list is illustrated with a single item 
shown in detail. As is shown, in the illustrated embodiment the user can add the item to 
the user's shopping cart via selection box 3410, and can then modify the default delivery 
Ci address information that is associated with the item. Alternately, the user can use the 
2d5 single-action ordering button 3425 to purchase the item and send it to the delivery address 
ll of the pre-selected procurement option 3420. In some embodiments the payment 
C J information associated with the pre-selected procurement option may be used to purchase 
the item, while in other embodiments such information may be retrieved from another 
source (e.g,, the default procurement option, from payment information previously 
20 associated with the wish list recipient or the item, etc.). In addition, in some 
embodiments a threshold may exist such that default payment information will be used 
only if the amount to purchase the item is below the threshold. 

In the illustrated embodiment, other procurement options cannot be selected 
and used along with the pre-selected delivery address (e.g., using the payment 
25 information and shipping instructions of another procurement option). This ability to use 
some or all of the information from procurement options other than the default or pre- 
selected procurement option may, however, be available in other embodiments. In 
addition, in some embodiments when a new procurement option is created while ordering 
an item from a wish list (e.g., by combining delivery address information from one 
30 procurement option with other procurement information from another procurement 
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option), this new procurement option is added to the user's address book. In other 
embodiments the user may be queried as to whether to add the new procurement option, 
or it may not be possible to add the new procurement option to the address book. 

hi addition to purchasing the item, the user can also select link 3405 in 
5 order to see a detailed item description Web page. In the illustrated embodiment, this 
detailed item description Web page will have a format similar to that displayed in Figure 
31 A. However, in the illustrated embodiment the currently selected procurement option 
shown in the current procurement option display 3103b will be modified to be the pre- 

n 

yj selected procurement option rather than the default procurement option. Sumlarly, the 
gift indication selection option 3103e will be selected since items purchased fi*om a wish 
" J list are typically purchased as gifts. Those skilled in the art will appreciate that in other 

L } 

J! embodiments, the display of the detailed item description Web page could be altered in a 

y variety of ways. 

Figure 35 illustrates an embodiment of a post-order summary page from 

H15 which order options can be modified. In particular, in the illustrated embodiment a 

A Thank You page is displayed in which a single-action order is confirmed, various aspects 
of the order and the supplying of the item (e.g., gift wrapping instructions and a gift 
message) are displayed and can be modified, and various options are presented to allow 
the user to continue shopping (e.g., showing items related to the just-purchased item). 
20 Those skilled in the art will appreciate that the embodiments shown in 

Figures 31A-31G, 32A-32B, and 33-35 are for illustrative purposes only, and are not 
intended to limit the scope of the invention. A user can perform a multi-procurement 
option ordering of one or more items using one of multiple available procurement options 
in a variety of ways. 

25 Although the present invention has been described in terms of various 

embodiments, it is not intended that the invention be limited to these embodiments. 
Modification within the spirit of the invention will be apparent to those skilled in the art. 
For example, the server system can map a client identifier to multiple customers who 
have recently used the client system. The server system can then allow the user to 

30 identify themselves by selecting one of the mappings based preferably on a display of 
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partial purchaser-specific order information. Also, various different single actions can be 
used to effect the placement of an order. For example, a voice command may be spoken 
by the purchaser, a key may be depressed by the purchaser, a button on a television 
remote control device may be depressed by the purchaser, or selection using any pointing 
device may be effected by the purchaser. Although a single action may be preceded by 
multiple physical movements of the purchaser (e.g., moving a mouse so that a mouse 
pointer is over a button, displaying a list of possible procurement options), the single 
action generally refers to a single event received by a client system that indicates to place 
the order. Finally, the purchaser can be altemately identified by a unique customer 
identifier that is provided by the customer when the customer initiates access to the server 
system and sent to the server system with each message. This customer identifier could 
be also stored persistently on the client system so that the purchaser does not need to re- 
enter their customer identifier each time access is initiated. The scope of the present 
invention is defined by the claims that follow. 
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